SerialICE www_serialice_com https://www.serialice.com/Main_Page MediaWiki 1.40.0 first-letter Media Special Talk User User talk SerialICE SerialICE talk File File talk MediaWiki MediaWiki talk Template Template talk Help Help talk Category Category talk 0 1 1 2012-12-18T17:08:54Z MediaWiki default 0 wikitext text/x-wiki '''MediaWiki has been successfully installed.''' Consult the [//meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software. == Getting started == * [//www.mediawiki.org/wiki/Manual:Configuration_settings Configuration settings list] * [//www.mediawiki.org/wiki/Manual:FAQ MediaWiki FAQ] * [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list] b7a3846f2c55072191227d89a3204fe379288fee 3 1 2012-12-18T17:56:06Z Patrick Georgi 1 wikitext text/x-wiki = SerialICE = SerialICE is a flexible, software based system software debugger. Based on the open source processor emulator Qemu, SerialICE allows you to log and intercept hardware accesses of your firmware and single step your firmware with the GNU debugger. == Using SerialICE == * [[Download]] * [[Installation]] * [[Getting Started]] * [[Debugging]] * [[Scripting]] * [[Hardware]] * [[Discussing SerialICE]] 3d674367fbff16a3618b8491872034eba28a003f 5 3 2012-12-18T18:06:58Z Patrick Georgi 1 wikitext text/x-wiki = SerialICE = SerialICE is a flexible, software based system software debugger. Based on the open source processor emulator Qemu, SerialICE allows you to log and intercept hardware accesses of your firmware and single step your firmware with the GNU debugger. == Using SerialICE == * [[Download]] * [[Installation]] * [[Getting Started]] * [[Debugging]] * [[Scripting]] * [[Hardware]] * [http://www.serialice.com/mailman/listinfo/serialice Discussing SerialICE] 64c0772f023eb4af846f5cfec53d6cf1275f1cf0 10 5 2012-12-18T18:44:26Z Patrick Georgi 1 wikitext text/x-wiki = SerialICE = SerialICE is a flexible, software based system software debugger. Based on the open source processor emulator Qemu, SerialICE allows you to log and intercept hardware accesses of your firmware and single step your firmware with the GNU debugger. == Using SerialICE == * [[Download]] * [[Installation]] * [[Getting Started]] * [[Debugging]] * [[Scripting]] * [[Make SerialICE work on new hardware]] * [http://www.serialice.com/mailman/listinfo/serialice Discussing SerialICE] 5f19faf976d1dc2759bbd010cb972851857f3ef4 15 10 2013-03-07T18:57:11Z Idwer 6 /* Using SerialICE */ wikitext text/x-wiki = SerialICE = SerialICE is a flexible, software based system software debugger. Based on the open source processor emulator Qemu, SerialICE allows you to log and intercept hardware accesses of your firmware and single step your firmware with the GNU debugger. == Using SerialICE == * [[Download]] * [[Installation]] * [[Getting Started]] * Interpreting qemu output: [[Log_file]] * [[Debugging]] * [[Scripting]] * [[Make SerialICE work on new hardware]] * [http://www.serialice.com/mailman/listinfo/serialice Discussing SerialICE] f07fd27af3821762457fd4d7256f338f24db295b 20 15 2013-03-17T21:28:37Z Kmalkki 5 wikitext text/x-wiki = SerialICE = SerialICE is a flexible, software based system software debugger. Based on the open source processor emulator Qemu, SerialICE allows you to log and intercept hardware accesses of your firmware and single step your firmware with the GNU debugger. After a couple of quiet years on the development front, it has now adopted new filtering subsystem. A number of [[GSoC | project ideas]] have been presented for candidates to [http://www.google-melange.com/gsoc/homepage/google/gsoc2013 Google Summer of Code 2013] program. == Using SerialICE == * [[Download]] * [[Installation]] * [[Getting Started]] * Interpreting qemu output: [[Log_file]] * [[Debugging]] * [[Scripting]] * [[Make SerialICE work on new hardware]] * [http://www.serialice.com/mailman/listinfo/serialice Discussing SerialICE] 36187f2982d6be9286479e4de4d0439573e0a322 24 20 2014-07-04T18:13:51Z Stefan Reinauer 2 wikitext text/x-wiki = SerialICE = SerialICE is a flexible, software based system software debugger. Based on the open source processor emulator Qemu, SerialICE allows you to log and intercept hardware accesses of your firmware and single step your firmware with the GNU debugger. After a couple of quiet years on the development front, it has now adopted new filtering subsystem. A number of [[GSoC | project ideas]] have been presented for candidates to [http://www.google-melange.com/gsoc/homepage/google/gsoc2013 Google Summer of Code 2013] program. == Using SerialICE == * [[Download]] * [[Installation]] * [[Getting Started]] * Interpreting qemu output: [[Log_file]] * [[Debugging]] * [[Scripting]] * [[Make SerialICE work on new hardware]] * [http://www.serialice.com/mailman/listinfo/serialice Discussing SerialICE] * [[Related Projects]] 39b901c9769b16958d363bbfd73f6441cfd5cb51 29 24 2015-02-25T10:29:58Z Kmalkki 5 wikitext text/x-wiki = SerialICE = SerialICE is a flexible, software based system software debugger. Based on the open source processor emulator Qemu, SerialICE allows you to log and intercept hardware accesses of your firmware and single step your firmware with the GNU debugger. After a couple of quiet years on the development front, it has now adopted new filtering subsystem. A number of [[GSoC | project ideas]] have been presented for candidates to [http://www.google-melange.com/gsoc/homepage/google/gsoc2015 Google Summer of Code 2015] program. == Using SerialICE == * [[Download]] * [[Installation]] * [[Getting Started]] * Interpreting qemu output: [[Log_file]] * [[Debugging]] * [[Scripting]] * [[Make SerialICE work on new hardware]] * [http://www.serialice.com/mailman/listinfo/serialice Discussing SerialICE] * [[Related Projects]] ab00a7af8cd79a91efd086e6733e09ad8f56ba4f 32 29 2016-03-02T22:06:15Z Stefan Reinauer 2 /* SerialICE */ wikitext text/x-wiki = SerialICE = SerialICE is a flexible, software based system software debugger. Based on the open source processor emulator Qemu, SerialICE allows you to log and intercept hardware accesses of your firmware and single step your firmware with the GNU debugger. After a couple of quiet years on the development front, it has now adopted new filtering subsystem. A number of [[GSoC | project ideas]] have been presented for candidates to [http://www.google-melange.com/gsoc/homepage/google/gsoc2016 Google Summer of Code 2016] program. == Using SerialICE == * [[Download]] * [[Installation]] * [[Getting Started]] * Interpreting qemu output: [[Log_file]] * [[Debugging]] * [[Scripting]] * [[Make SerialICE work on new hardware]] * [http://www.serialice.com/mailman/listinfo/serialice Discussing SerialICE] * [[Related Projects]] f6a2298386d37b19472079e3ad7838fb91dbe6f6 33 32 2016-03-02T22:08:15Z Stefan Reinauer 2 wikitext text/x-wiki = SerialICE = SerialICE is a flexible, software based system software debugger. Based on the open source processor emulator Qemu, SerialICE allows you to log and intercept hardware accesses of your firmware and single step your firmware with the GNU debugger. After a couple of quiet years on the development front, it has now adopted new filtering subsystem. Want to work on SerialICE this summer? Check out our [[GSoC | project ideas]] for the [https://summerofcode.withgoogle.com/ Google Summer of Code 2016] program. == Using SerialICE == * [[Download]] * [[Installation]] * [[Getting Started]] * Interpreting qemu output: [[Log_file]] * [[Debugging]] * [[Scripting]] * [[Make SerialICE work on new hardware]] * [http://www.serialice.com/mailman/listinfo/serialice Discussing SerialICE] * [[Related Projects]] c9bb0151c00d5c6b6c69d7e893a9a323c68c580a 6 2 2 2012-12-18T17:44:29Z Patrick Georgi 1 wikitext text/x-wiki da39a3ee5e6b4b0d3255bfef95601890afd80709 0 3 4 2012-12-18T18:04:44Z Patrick Georgi 1 Created page with "= Building SerialICE = $ cd SerialICE $ make menuconfig $ make You can now flash the 64KB serialice.rom onto your mainboard's ROM chip (you must pad or "multiply" it t..." wikitext text/x-wiki = Building SerialICE = $ cd SerialICE $ make menuconfig $ make You can now flash the 64KB serialice.rom onto your mainboard's ROM chip (you must pad or "multiply" it to your ROM chip's size before): $ cat serialice.rom serialice.rom serialice.rom serialice.rom > serialice_256kb.rom $ flashrom -w serialice_256kb.rom Before you continue, please check with a terminal program of your choice (eg [http://alioth.debian.org/projects/minicom minicom], [http://code.google.com/p/picocom/ picocom]) that you are seeing a SerialICE shell prompt: SerialICE v1.5 (Nov 20 2009) > CTRL-A Z for help |115200 8N1 | NOR | Minicom 2.3 | VT102 | Offline = Building QEMU = You need to build a patched QEMU from source, and you will need Lua >= 5.2. To build Qemu you can run the build script that was added by the SerialICE patch: $ sh build.sh You are now ready to start using SerialICE. [[Getting Started]] provides an intro to using SerialICE, [[Debugging]] provides some information about using gdb with SerialICE targets, and [[Scripting]] describes the scripting abilities of SerialICE. ba118720e066598af03be2f5352dd4d52d308b78 18 4 2013-03-09T11:58:45Z Kmalkki 5 wikitext text/x-wiki = Building SerialICE = Take note of the size of the flash chip you will use for SerialICE and set that correctly while in menuconfig. $ cd SerialICE $ make menuconfig $ make You can now flash the serialice.rom image. You can execute flashrom on the target machine like this: $ flashrom -p internal -w serialice.rom You can also use external programmer devices. In either case, keep a copy of the original mainboard bios image, preferably use a different chip for SerialICE purposes. After programming the flash, do a cold reboot of the target machine. Next check with a terminal program of your choice (eg [http://alioth.debian.org/projects/minicom minicom], [http://code.google.com/p/picocom/ picocom]) that you are seeing a SerialICE shell prompt. If you do not get a prompt, see [[Make_SerialICE_work_on_new_hardware]]. SerialICE v1.5 (Nov 20 2012) > CTRL-A Z for help |115200 8N1 | NOR | Minicom 2.3 | VT102 | Offline = Building QEMU = You need to build a patched QEMU from source, and you will need Lua >= 5.2. To build Qemu you can run the build script that was added by the SerialICE patch: $ sh build.sh You are now ready to start using SerialICE. [[Getting Started]] provides an intro to using SerialICE, while [[Log_file]] explains the output format. Advanced topics like [[Debugging]] have information about using gdb with SerialICE targets, and [[Scripting]] describes the basics of writing filters to match the hardware. f030369faad2cdbe18005ca61a67b0c90579517d 0 4 6 2012-12-18T18:33:58Z Patrick Georgi 1 Created page with "= Getting Started - First Steps With SerialICE = Connect the target to your computer. Figure out the serial port that you can use to talk to it. Relative to the qemu directory..." wikitext text/x-wiki = Getting Started - First Steps With SerialICE = Connect the target to your computer. Figure out the serial port that you can use to talk to it. Relative to the qemu directory in the SerialICE tree, call $ ./i386-softmmu/qemu -M serialice -serialice /dev/ttyUSB0 -hda /dev/zero -bios /your/bios/image > logfile.txt This assumes that /dev/ttyUSB0 is your serial port. Replace as appropriate. You'll get a log file that looks like this: SerialICE: Open connection to target hardware... SerialICE: Waiting for handshake with target... target alife! SerialICE: LUA init... SerialICE: Starting LUA script SerialICE: Registering physical memory areas for Cache-As-Ram: Registering physical memory at 0xffd80000 (0x00080000 bytes) Registering physical memory at 0xffbc0000 (0x00040000 bytes) SerialICE: LUA script initialized. MEM: readb fffffff0 => ea MEM: readw fffffff1 => ffaa MEM: readw fffffff3 => f000 MEM: readb 000fffaa => e9 MEM: readw 000fffab => 00c3 MEM: readb 000f0070 => e9 MEM: readw 000f0071 => 01cd ... IO: outb 0080 <= d0 CPU: CPUID eax: 00000000; ecx: 00000000 => 00000006.756e6547.6c65746e.49656e69 CPU: CPUID eax: 00000001; ecx: 6c65746e => 000006e8.00020800.0000c1a9.bfe9fbff MEM: readw 000f0a53 => 06e0 CPU: CPUID eax: 00000004; ecx: 00000000 => 04000121.01c0003f.0000003f.00000001 ... IO: outb 0070 <= 8e IO: inb 0071 => 48 ... CPU: rdmsr 000002ff => 00000000.00000000 CPU: wrmsr 000002ff <= 00000000.00000000 CPU: wrmsr 00000250 <= 00000000.00000000 ... IO: outl 0cf8 <= 8000f8f0 IO: outl 0cfc <= fed1c001 PCI 0:1f.0 R.f0 00dbf6baa4bdc1bdde14e1d2803a6778a4cb40e0 7 6 2012-12-18T18:35:06Z Patrick Georgi 1 wikitext text/x-wiki = First Steps With SerialICE = Connect the target to your computer. Figure out the serial port that you can use to talk to it. Relative to the qemu directory in the SerialICE tree, call $ ./i386-softmmu/qemu -M serialice -serialice /dev/ttyUSB0 -hda /dev/zero -bios /your/bios/image > logfile.txt This assumes that /dev/ttyUSB0 is your serial port. Replace as appropriate. You'll get a log file that looks like this: SerialICE: Open connection to target hardware... SerialICE: Waiting for handshake with target... target alife! SerialICE: LUA init... SerialICE: Starting LUA script SerialICE: Registering physical memory areas for Cache-As-Ram: Registering physical memory at 0xffd80000 (0x00080000 bytes) Registering physical memory at 0xffbc0000 (0x00040000 bytes) SerialICE: LUA script initialized. MEM: readb fffffff0 => ea MEM: readw fffffff1 => ffaa MEM: readw fffffff3 => f000 MEM: readb 000fffaa => e9 MEM: readw 000fffab => 00c3 MEM: readb 000f0070 => e9 MEM: readw 000f0071 => 01cd ... IO: outb 0080 <= d0 CPU: CPUID eax: 00000000; ecx: 00000000 => 00000006.756e6547.6c65746e.49656e69 CPU: CPUID eax: 00000001; ecx: 6c65746e => 000006e8.00020800.0000c1a9.bfe9fbff MEM: readw 000f0a53 => 06e0 CPU: CPUID eax: 00000004; ecx: 00000000 => 04000121.01c0003f.0000003f.00000001 ... IO: outb 0070 <= 8e IO: inb 0071 => 48 ... CPU: rdmsr 000002ff => 00000000.00000000 CPU: wrmsr 000002ff <= 00000000.00000000 CPU: wrmsr 00000250 <= 00000000.00000000 ... IO: outl 0cf8 <= 8000f8f0 IO: outl 0cfc <= fed1c001 PCI 0:1f.0 R.f0 5b9360e0386dc453d3db62532a7415c506ef4216 16 7 2013-03-09T11:25:57Z Kmalkki 5 /* First Steps With SerialICE */ wikitext text/x-wiki = First Steps With SerialICE = Connect the target to your computer. Figure out the serial port that you can use to talk to it. Relative to the qemu directory in the SerialICE tree, call $ cd SerialICE/simba $ ln -sf ../../qemu-0.15.x/i386-softmmu/qemu $ ./qemu -M serialice -serialice /dev/ttyUSB0 -singlestep -bios /your/bios/image > logfile.txt This assumes that /dev/ttyUSB0 is your serial port. Replace as appropriate. You'll get a logfile.txt something like this: <nowiki> SerialICE: Open connection to target hardware... SerialICE: Waiting for handshake with target... target alive! SerialICE: Version.....: SerialICE v1.5 (Feb 19 2013) SerialICE: Mainboard...: Commell LV-672 SerialICE: LUA init... SerialICE: LUA init... SerialICE: Starting LUA script SerialICE: LUA script initialized. Registering physical memory at 0xffdf8000 (0x00008000 bytes) VNC server running on `127.0.0.1:5900' 0000.0001 R.Q. [ffff000:fff0] MEM: readb fffffff0 => e9 0000.0002 R.Q. [ffff000:fff0] MEM: readw fffffff1 => f00d 0003.0004 RH.. [ffff000:f006] IO: outb 0080 <= 01 0003.0005 R.Q. [ffff000:f018] MEM: readl fffff04e => 00000000 0003.0006 R.Q. [ffff000:f01c] MEM: readw fffff01d => f044 0003.0007 R.Q. [ffff000:f021] MEM: readl fffff046 => fffff054 0003.0008 R.Q. [ffff000:f029] MEM: readl fffff02b => 7ffaffd1 0003.0009 R.Q. [ffff000:f02f] MEM: readl fffff031 => 60000001 0003.000a R.Q. [ffff000:f038] MEM: readb fffff038 => 66 0003.000b R.Q. [ffff000:f03b] MEM: readl fffff03d => fffff07b 0003.000c R.Q. [ffff000:f03b] MEM: readw fffff041 => 0008 0003.000d RH.. [0000:fffff07f] IO: outb 0080 <= 10 0003.000e R.Q. [0000:fffff081] MEM: readw fffff083 => 0010 0003.000f R.Q. [0000:fffff096] MEM: readl fffff097 => 00000200 0003.0010 R.Q. [0000:fffff0a4] MEM: readl fffff0a5 => 0000001b 0011.0012 RH.U [0000:fffff0a9] CPU MSR: [0000001b] => 00000000.fee00900 0011.0013 R.Q. [0000:fffff0b4] MEM: readl fffff0b5 => 8000f8dc 0011.0014 R.Q. [0000:fffff0b9] MEM: readw fffff0bb => 0cf8 0016.0017 RH.. [0000:fffff0bd] IO: outl 0cf8 <= 8000f8dc 0016.0018 RH.. [0000:fffff0c2] IO: inb 0cfc => 00 0016.0019 R.Q. [0000:fffff0d0] MEM: readl fffff0d1 => 8000f8dc 0016.001a R.Q. [0000:fffff0d5] MEM: readw fffff0d7 => 0cf8 001b.001c RH.. [0000:fffff0d9] IO: outl 0cf8 <= 8000f8dc 001b.001d RH.. [0000:fffff0e2] IO: outb 0cfc <= 08 001b.001e R.Q. [0000:fffff0e8] MEM: readl fffff0e9 => fffff0ef 001b.001f R.Q. [0000:fffff105] MEM: readl fffff106 => fffffffc 001b.0020 R.Q. [0000:fffff10a] MEM: readl ffffefe8 => 00000800 001b.0021 R.Q. [0000:fffff11d] MEM: readl fffff11e => 00000000 001b.0022 R.Q. [0000:fffff130] MEM: readl fff80000 => 4352414c 001b.0023 R.Q. [0000:fffff132] MEM: readl fffff1b2 => 4352414c 001b.0024 R.Q. [0000:fffff13d] MEM: readl fffff13f => fffff1b6 001b.0025 R.Q. [0000:fffff13d] MEM: readl fffff1b6 => 45564948 001b.0026 R.Q. [0000:fff8006c] MEM: readl fff80056 => fff80054 001b.0027 R.Q. [0000:fff80074] MEM: readl fff80075 => fff8007b 001b.0028 R.Q. [0000:fff80074] MEM: readw fff80079 => 0008 0029.002a RH.. [0000:fff8007f] IO: outb 0080 <= 10 0029.002b R.Q. [0000:fff80081] MEM: readw fff80083 => 0010 0029.002c RH.. [0000:fff800b1] IO: outb 0080 <= 20 002d.002e RH.U [0000:fff800b8] CPU MSR: [0000001b] => 00000000.fee00900 002d.002f R.Q. [0000:fff800ba] MEM: readl fff800bb => 00000100 002d.0030 R.Q. [0000:fff800bf] MEM: readl fff800c1 => 00000158 002d.0031 R.Q. [0000:fff800c5] MEM: readl fff800c6 => fff803fb 002d.0032 R.Q. [0000:fff800ca] MEM: readl fff800cb => 0000001b 002d.0033 R.Q. [0000:fff800d3] MEM: readw fff803fb => 0250 </nowiki> This is referred to as the raw logfile from qemu session. It usually shows more detail than you care to look at, so you will want to further process this through a replay script. $ cat logfile.txt | lua replay.lua The interesting part of the log is below, where loads from flash memory are hidden and PCI configuration access is translated. You can control the verbosity of the replayer with the parameters in user_env.lua file. <nowiki> 0003.0004 .H.. [ffff000:f006] POST: *** 01 *** 0003.000d .H.. [0000:fffff07f] POST: *** 10 *** 0011.0012 RH.U [0000:fffff0a9] CPU MSR: [0000001b] => 00000000.fee00900 0016.0018 .H.. [0000:fffff0c2] PCI: 0:1f.0 [0dc] => 00 001b.001d .H.. [0000:fffff0e2] PCI: 0:1f.0 [0dc] <= 08 0029.002a .H.. [0000:fff8007f] POST: *** 10 *** 0029.002c .H.. [0000:fff800b1] POST: *** 20 *** 002d.002e RH.U [0000:fff800b8] CPU MSR: [0000001b] => 00000000.fee00900 </nowiki> 6675935ab7731e00f2cbbaf69601804d1eb40400 0 5 8 2012-12-18T18:41:52Z Patrick Georgi 1 Created page with "After you started the SerialICE patched Qemu, you can start a gdbserver via the Qemu monitor. To enter the Qemu monitor, click into the Qemu "VGA window" and press CTRL-ALT-2...." wikitext text/x-wiki After you started the SerialICE patched Qemu, you can start a gdbserver via the Qemu monitor. To enter the Qemu monitor, click into the Qemu "VGA window" and press CTRL-ALT-2. The virtual machine will continue executing code while you are in the monitor. Here you can start a gdbserver on port 1234 by typing: gdbserver Alternatively, you can start QEmu with the arguments -s -S, which automatically puts QEmu in gdbserver mode and stops it at the entry point. you can then connect gdb as described below. == Connect with GDB == $ i386-elf-gdb GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i386-apple-darwin9.6.0 --target=i386-elf". (gdb) Now set the target architecture to i8086 (16bit) (gdb) set architecture i8086 The target architecture is assumed to be i8086 and connect to the "remote machine" (gdb) target remote localhost:1234 Remote debugging using localhost:1234 [New Thread 1] 0x0000084a in ?? () Note: The IP is a real mode IP. You need to look at the CS to find out where your code really lives. To disassemble code at the current position, you can do this: (gdb) x/5i ($cs*16)+$eip 0xec23c:loop 0xec226 0xec23e:mov %bh,%al 0xec240:out %al,$0x61 0xec242:ret 0xec243:lcall $0xe5db,$0x1ac0 (gdb) Now for the fun part: Look at the registers with (gdb) info reg eax 0x2e03023015426 ecx 0x1d2466 edx 0x302770 ebx 0x300112289 esp 0x16310x1631 ebp 0x54a00030x54a0003 esi 0xe00357347 edi 0x11 eip 0x38ec0x38ec eflags 0x12[ AF ] cs 0xe89559541 ss 0xe89559541 ds 0x18386200 es 0x00 fs 0xe5db58843 gs 0xe89559541 (gdb) Or, with a little bit of context: (gdb) x/20i ($cs*16)+$eip - 0x10 prints 20 instructions, starting 0x10 before the current CS:IP. Of course you can also change registers: (gdb) set var $ecx=0x20 (gdb) print $ecx $1 = 32 (gdb) This is an excellent method to skip long loops. Now you can continue code execution with (gdb) c Continuing. Go back to the GDB shell at any time with CTRL-C ^C Program received signal SIGINT, Interrupt. 0x000038d6 in ?? () (gdb) This will output the current instruction each time you call nexti, stepi, etc.: (gdb) display /i ($cs * 16) + $pc It's possible to trace execution with (gdb) while 1 > stepi > end (newlines are necessary) That snippet is useful to find out the code flow and pinpoint a crash to an instruction. 0bce285747dfa3f7e156b55e657d33482022b00b 0 6 9 2012-12-18T18:43:44Z Patrick Georgi 1 Created page with "SerialICE runs all hardware accesses through a set of filter and log functions. These functions are written in the scripting language LUA. This allows to customize it to your ..." wikitext text/x-wiki SerialICE runs all hardware accesses through a set of filter and log functions. These functions are written in the scripting language LUA. This allows to customize it to your specific needs without changing the Qemu portion of SerialICE. (TODO: Add current documentation on filters) 3d7384df8f26171d96a9e7d6b2cf1cb55a42c466 0 7 11 2012-12-18T18:46:53Z Patrick Georgi 1 Created page with "Though it is designed to be as generic as possible the SerialICE shell needs a little bit of hardware specific initialization code for each supported mainboard. There is one f..." wikitext text/x-wiki Though it is designed to be as generic as possible the SerialICE shell needs a little bit of hardware specific initialization code for each supported mainboard. There is one file per mainboard with this initialization code in the mainboard/ directory. The purpose of the initialization code is to get the machine far enough to be able to talk via serial console. This usually requires setup of the Super I/O chip and some southbridge registers. In some cases extra work may have to be done, like disabling a power-on watchdog timer, enabling a fan(!), or enabling some devices "on the path to the Super I/O". Here is some simple example: <nowiki> /* Hardware specific functions */ #define PMBASE 0x100 #define TCOBASE 0x60 #define TCO1_CNT 0x08 static void southbridge_init(void) { /* Prevent the TCO timer from rebooting */ /* Set ACPI base address (I/O space). */ pci_write_config32(PCI_ADDR(0, 0x1f, 0, 0x40), (PMBASE | 1)); /* Enable ACPI I/O. */ pci_write_config8(PCI_ADDR(0, 0x1f, 0, 0x44), 0x10); /* Halt the TCO timer, preventing SMI and automatic reboot */ outw(inw(PMBASE + TCOBASE + TCO1_CNT) | (1 << 11), PMBASE + TCOBASE + TCO1_CNT); } static void superio_init(void) { /* Enter the configuration state. */ pnp_enter_ext_func_mode_alt(0x2e); /* COM A */ pnp_set_logical_device(0x2e, 4); pnp_set_enable(0x2e, 0); pnp_set_iobase0(0x2e, 0x3f8); pnp_set_irq0(0x2e, 4); pnp_set_enable(0x2e, 1); /* Exit the configuration state. */ pnp_exit_ext_func_mode(0x2e); } static void chipset_init(void) { southbridge_init(); superio_init(); } </nowiki> c1825b9f3bef858e995034a28e4a5dbee15d45fb 0 8 12 2012-12-18T18:50:44Z Patrick Georgi 1 Created page with "SerialICE is managed by [http://review.coreboot.org coreboot's gerrit instance]. For contributions see [http://www.coreboot.org/Git coreboot's git documentation]. SerialICE sh..." wikitext text/x-wiki SerialICE is managed by [http://review.coreboot.org coreboot's gerrit instance]. For contributions see [http://www.coreboot.org/Git coreboot's git documentation]. SerialICE shares their rules and workflow. You can pull from git at http://review.coreboot.org/p/serialice.git 57972f423d710c9bab4ba021b5479d9010f36073 0 9 13 2013-03-07T13:30:01Z Idwer 6 Initial page, just putting most of a commit message here. wikitext text/x-wiki First number pair is a running index that could be used to group and indent the lines to improve readability. Second string is combination of flags telling how action got processed: I Info -- informational line only R Raw -- raw IO/MEMORY/CPU operation H Hardware -- action was sent to target Q Qemu -- action was sent to qemu U Undefined -- action hit the fallback filter D Dropped -- filter prevented sending action to target or qemu F Faked -- filter modified the action on-the-fly Third field is the instruction pointer [CS:EIP]. Remaining of the line describes the action. A few examples: Memory access, Raw + Qemu. Following is read of vector stored in the BIOS image file. 0000.0001 RQ.. [ffff000:fff0] MEM,ROM_HI: readb fffffff0 => ea 0000.0002 RQ.. [ffff000:fff0] MEM,ROM_HI: readw fffffff1 => e05b 0000.0003 RQ.. [ffff000:fff0] MEM,ROM_HI: readw fffffff3 => f000 PCI config read, Hardware. This is composed from either IO accesses to 0xcf8-0xcff or memory access to a specific PCI-e MM config region. Thus it is not Raw but a composed action. 0044.0046 .H.. [f000:f764] PCI: 0:1e.0 [004] => 00 CPUID, Raw + Hard + Faked. CPUID was executed on the target, but the returned value was modified. In this case, it fakes CPU has a single core. 000d.000e RH.F [f000:e814] CPUID: eax: 00000001; ecx: 00000000 => 00000f4a.00010800.0000649d.bfebfbff RDMSR Raw + Hard and WRMSR Raw + Dropped. In this case, requst to do microcode update in target CPU is dropped as our serialice.rom image doesn't contain that binary. 0019.001a RH.. [f000:e869] CPU MSR: [00000017] => 00120000.00000000 001c.001d R..D [f000:e88e] CPU MSR: [00000079] <= 00000000.fffdfc10 <br>(The above is taken from the commit message found at http://review.coreboot.org/#/c/2511/ and was slightly edited) cd6d74d7e948214fa5b1689070b76585e538966d 14 13 2013-03-07T13:39:03Z Idwer 6 added a little introduction wikitext text/x-wiki This page describes the structure of qemu output, when running qemu as is explained here: http://www.serialice.com/Getting_Started First number pair is a running index that could be used to group and indent the lines to improve readability. Second string is combination of flags telling how action got processed: I Info -- informational line only R Raw -- raw IO/MEMORY/CPU operation H Hardware -- action was sent to target Q Qemu -- action was sent to qemu U Undefined -- action hit the fallback filter D Dropped -- filter prevented sending action to target or qemu F Faked -- filter modified the action on-the-fly Third field is the instruction pointer [CS:EIP]. Remaining of the line describes the action. A few examples: Memory access, Raw + Qemu. Following is read of vector stored in the BIOS image file. 0000.0001 RQ.. [ffff000:fff0] MEM,ROM_HI: readb fffffff0 => ea 0000.0002 RQ.. [ffff000:fff0] MEM,ROM_HI: readw fffffff1 => e05b 0000.0003 RQ.. [ffff000:fff0] MEM,ROM_HI: readw fffffff3 => f000 PCI config read, Hardware. This is composed from either IO accesses to 0xcf8-0xcff or memory access to a specific PCI-e MM config region. Thus it is not Raw but a composed action. 0044.0046 .H.. [f000:f764] PCI: 0:1e.0 [004] => 00 CPUID, Raw + Hard + Faked. CPUID was executed on the target, but the returned value was modified. In this case, it fakes CPU has a single core. 000d.000e RH.F [f000:e814] CPUID: eax: 00000001; ecx: 00000000 => 00000f4a.00010800.0000649d.bfebfbff RDMSR Raw + Hard and WRMSR Raw + Dropped. In this case, requst to do microcode update in target CPU is dropped as our serialice.rom image doesn't contain that binary. 0019.001a RH.. [f000:e869] CPU MSR: [00000017] => 00120000.00000000 001c.001d R..D [f000:e88e] CPU MSR: [00000079] <= 00000000.fffdfc10 <br>(The above is taken from the commit message found at http://review.coreboot.org/#/c/2511/ and was slightly edited) 4c609a73851938fd9fd43593ca59fbf6312ac93f 17 14 2013-03-09T11:29:27Z Kmalkki 5 wikitext text/x-wiki This page describes the structure of a replayed output. Running qemu is explained here: http://www.serialice.com/Getting_Started First number pair is a running index that could be used to group and indent the lines to improve readability. Second string is combination of flags telling how action got processed: I Info -- informational line only R Raw -- raw IO/MEMORY/CPU operation H Hardware -- action was sent to target Q Qemu -- action was sent to qemu U Undefined -- action hit the fallback filter D Dropped -- filter prevented sending action to target or qemu F Faked -- filter modified the action on-the-fly Third field is the instruction pointer [CS:EIP]. Remaining of the line describes the action. A few examples: Memory access, Raw + Qemu. Following is read of vector stored in the BIOS image file. 0000.0001 R.Q. [ffff000:fff0] MEM,ROM_HI: readb fffffff0 => ea 0000.0002 R.Q. [ffff000:fff0] MEM,ROM_HI: readw fffffff1 => e05b 0000.0003 R.Q. [ffff000:fff0] MEM,ROM_HI: readw fffffff3 => f000 PCI config read, Hardware. This is composed from either IO accesses to 0xcf8-0xcff or memory access to a specific PCI-e MM config region. Thus it is not Raw but a composed action. 0044.0046 .H.. [f000:f764] PCI: 0:1e.0 [004] => 00 CPUID, Raw + Hard + Faked. CPUID was executed on the target, but the returned value was modified. In this case, it fakes CPU has a single core. 000d.000e RH.F [f000:e814] CPUID: eax: 00000001; ecx: 00000000 => 00000f4a.00010800.0000649d.bfebfbff RDMSR Raw + Hard and WRMSR Raw + Dropped. In this case, requst to do microcode update in target CPU is dropped as our serialice.rom image doesn't contain that binary. 0019.001a RH.. [f000:e869] CPU MSR: [00000017] => 00120000.00000000 001c.001d R..D [f000:e88e] CPU MSR: [00000079] <= 00000000.fffdfc10 <br>(The above is taken from the commit message found at http://review.coreboot.org/#/c/2511/ and was slightly edited) b5bf6bc4d66353e7830031af0a846f76d160d7c7 0 10 19 2013-03-17T21:19:12Z Kmalkki 5 SerialICE Google Summer of Code 2013 wikitext text/x-wiki The SerialICE project will hopefully participate in GSoC 2013 under the patronage of [http://coreboot.org/GSoC coreboot's GSoC administration]. Depending on the number and quality of applications, and available mentors, there might be room for a separate SerialICE project. If you're interested, please send your thoughts and ideas on the [http://www.serialice.com/mailman/listinfo/serialice mailing list] and come discuss them on IRC irc://irc.freenode.net/#coreboot. It is not likely that the project organisation would supply any hardware required to complete or even start a project on SerialICE. So if you want to apply, you should first try building and running SerialICE yourself to understand its current capabilities and weaknesses. You really don't need a high-end mainboard or CPUs on these projects. While it's a powerful tool for low-level debugging and understanding even part of it requires a fair amount of knowledge on x86 architecture, there are also challenges in the user interface development. The list below is a collection of improvement ideas and capabilities that would be nice to have. Some of these could be merged with [http://www.coreboot.org/GSoC coreboot GSoC] projects or support [http://www.flashrom.org/GSoC flashrom GSoC] projects. == SerialICE on target == * Build target ROM image with super-IO and PnP from coreboot tree. * Support EHCI debug port, extend the protocol for memory block moves. * Investigate possibilities to catch SMI and run System Management Mode. == SIMBA, the filtering subsystem == * Query PCI IDs to detect chipsets and load filters automatically. * Enable modifying SMBus traffic on-the-fly to forge SPD data for testing purposes. * Create log output conditionally of CS:EIP or accessed PCI device. * Decode PCI/PCI-e standard configuration registers. * Enable injection of IO and memory transactions. == User interface == * Well, provide one. Now it is just a logfile and a script. * Display SerialICE log in parallel with disassembly. * Visualize PCI devicetree configuration sequence and allocations. * Integration with GDB and DDD. == Coreboot == * Collect IO and PCI transactions on boot and store them in cbmem. Replay them to see what devicetree really did during ramstage. * Complete and merge [http://www.coreboot.org/Project_Ideas#coreboot_panic_room coreboot panic room] results upstream. == QEMU == * Create hybrid platform, where some devices are emulated and some run on real hardware. * Update to QEMU v1.4. * Support other architectures. fa8fce6d880e1aa41c7d6e2db26a245fa4c54ef6 21 19 2013-03-27T12:58:45Z Idwer 6 /* User interface */ added application names wikitext text/x-wiki The SerialICE project will hopefully participate in GSoC 2013 under the patronage of [http://coreboot.org/GSoC coreboot's GSoC administration]. Depending on the number and quality of applications, and available mentors, there might be room for a separate SerialICE project. If you're interested, please send your thoughts and ideas on the [http://www.serialice.com/mailman/listinfo/serialice mailing list] and come discuss them on IRC irc://irc.freenode.net/#coreboot. It is not likely that the project organisation would supply any hardware required to complete or even start a project on SerialICE. So if you want to apply, you should first try building and running SerialICE yourself to understand its current capabilities and weaknesses. You really don't need a high-end mainboard or CPUs on these projects. While it's a powerful tool for low-level debugging and understanding even part of it requires a fair amount of knowledge on x86 architecture, there are also challenges in the user interface development. The list below is a collection of improvement ideas and capabilities that would be nice to have. Some of these could be merged with [http://www.coreboot.org/GSoC coreboot GSoC] projects or support [http://www.flashrom.org/GSoC flashrom GSoC] projects. == SerialICE on target == * Build target ROM image with super-IO and PnP from coreboot tree. * Support EHCI debug port, extend the protocol for memory block moves. * Investigate possibilities to catch SMI and run System Management Mode. == SIMBA, the filtering subsystem == * Query PCI IDs to detect chipsets and load filters automatically. * Enable modifying SMBus traffic on-the-fly to forge SPD data for testing purposes. * Create log output conditionally of CS:EIP or accessed PCI device. * Decode PCI/PCI-e standard configuration registers. * Enable injection of IO and memory transactions. == User interface == * Well, provide one. Now it is just a logfile and a script. * Display SerialICE log in parallel with disassembly. Decent disassembling applications are IDA and/or radare2: * https://www.hex-rays.com/products/ida/index.shtml * http://rada.re/y/?p=features * Visualize PCI devicetree configuration sequence and allocations. * Integration with GDB and DDD. == Coreboot == * Collect IO and PCI transactions on boot and store them in cbmem. Replay them to see what devicetree really did during ramstage. * Complete and merge [http://www.coreboot.org/Project_Ideas#coreboot_panic_room coreboot panic room] results upstream. == QEMU == * Create hybrid platform, where some devices are emulated and some run on real hardware. * Update to QEMU v1.4. * Support other architectures. 3413056ebd0c659ca79c77bf20afdfcd94474c79 22 21 2013-03-28T20:05:57Z Kmalkki 5 /* User interface */ wikitext text/x-wiki The SerialICE project will hopefully participate in GSoC 2013 under the patronage of [http://coreboot.org/GSoC coreboot's GSoC administration]. Depending on the number and quality of applications, and available mentors, there might be room for a separate SerialICE project. If you're interested, please send your thoughts and ideas on the [http://www.serialice.com/mailman/listinfo/serialice mailing list] and come discuss them on IRC irc://irc.freenode.net/#coreboot. It is not likely that the project organisation would supply any hardware required to complete or even start a project on SerialICE. So if you want to apply, you should first try building and running SerialICE yourself to understand its current capabilities and weaknesses. You really don't need a high-end mainboard or CPUs on these projects. While it's a powerful tool for low-level debugging and understanding even part of it requires a fair amount of knowledge on x86 architecture, there are also challenges in the user interface development. The list below is a collection of improvement ideas and capabilities that would be nice to have. Some of these could be merged with [http://www.coreboot.org/GSoC coreboot GSoC] projects or support [http://www.flashrom.org/GSoC flashrom GSoC] projects. == SerialICE on target == * Build target ROM image with super-IO and PnP from coreboot tree. * Support EHCI debug port, extend the protocol for memory block moves. * Investigate possibilities to catch SMI and run System Management Mode. == SIMBA, the filtering subsystem == * Query PCI IDs to detect chipsets and load filters automatically. * Enable modifying SMBus traffic on-the-fly to forge SPD data for testing purposes. * Create log output conditionally of CS:EIP or accessed PCI device. * Decode PCI/PCI-e standard configuration registers. * Enable injection of IO and memory transactions. == User interface == * Well, provide one. Now it is just a logfile and a script. * Display SerialICE log in parallel with disassembly. Applications to consider are [http://rada.re/y/?p=features radare2] and [https://www.hex-rays.com/products/ida/index.shtml IDA] * Visualize PCI devicetree configuration sequence and allocations. * Integration with GDB and DDD. == Coreboot == * Collect IO and PCI transactions on boot and store them in cbmem. Replay them to see what devicetree really did during ramstage. * Complete and merge [http://www.coreboot.org/Project_Ideas#coreboot_panic_room coreboot panic room] results upstream. == QEMU == * Create hybrid platform, where some devices are emulated and some run on real hardware. * Update to QEMU v1.4. * Support other architectures. 8a0f69a3a5474ba0dd766ac08e0dbd89bcd1d83b 23 22 2014-02-06T09:51:02Z Kmalkki 5 wikitext text/x-wiki The SerialICE project will hopefully participate in GSoC 2014 under the patronage of [http://coreboot.org/GSoC coreboot's GSoC administration]. Depending on the number and quality of applications, and available mentors, there might be room for a separate SerialICE project. If you're interested, please send your thoughts and ideas on the [http://www.serialice.com/mailman/listinfo/serialice mailing list] and come discuss them on IRC irc://irc.freenode.net/#coreboot. It is not likely that the project organisation would supply any hardware required to complete or even start a project on SerialICE. So if you want to apply, you should first try building and running SerialICE yourself to understand its current capabilities and weaknesses. You really don't need a high-end mainboard or CPUs on these projects. While it's a powerful tool for low-level debugging and understanding even part of it requires a fair amount of knowledge on x86 architecture, there are also challenges in the user interface development. The list below is a collection of improvement ideas and capabilities that would be nice to have. Some of these could be merged with [http://www.coreboot.org/GSoC coreboot GSoC] projects or support [http://www.flashrom.org/GSoC flashrom GSoC] projects. == SerialICE on target == * Build target ROM image with super-IO and PnP from coreboot tree. * Support EHCI debug port, extend the protocol for memory block moves. * Investigate possibilities to catch SMI and run System Management Mode. == SIMBA, the filtering subsystem == * Query PCI IDs to detect chipsets and load filters automatically. * Enable modifying SMBus traffic on-the-fly to forge SPD data for testing purposes. * Create log output conditionally of CS:EIP or accessed PCI device. * Decode PCI/PCI-e standard configuration registers. * Enable injection of IO and memory transactions. == User interface == * Well, provide one. Now it is just a logfile and a script. * Display SerialICE log in parallel with disassembly. Applications to consider are [http://rada.re/y/?p=features radare2] and [https://www.hex-rays.com/products/ida/index.shtml IDA] * Visualize PCI devicetree configuration sequence and allocations. * Integration with GDB and DDD. == Coreboot == * Collect IO and PCI transactions on boot and store them in cbmem. Replay them to see what devicetree really did during ramstage. * Complete and merge [http://www.coreboot.org/Project_Ideas#coreboot_panic_room coreboot panic room] results upstream. == QEMU == * Create hybrid platform, where some devices are emulated and some run on real hardware. * Update to QEMU v1.4. * Support other architectures. edb1bb4e2d68ffe0d76c5420e02803c07a7887fa 28 23 2015-02-22T22:32:08Z Stefanct 4 wikitext text/x-wiki The SerialICE project will hopefully participate in GSoC 2015 under the patronage of [http://coreboot.org/GSoC coreboot's GSoC administration]. Depending on the number and quality of applications, and available mentors, there might be room for a separate SerialICE project. If you're interested, please send your thoughts and ideas on the [http://www.serialice.com/mailman/listinfo/serialice mailing list] and come discuss them on IRC irc://irc.freenode.net/#coreboot. It is not likely that the project organisation would supply any hardware required to complete or even start a project on SerialICE. So if you want to apply, you should first try building and running SerialICE yourself to understand its current capabilities and weaknesses. You really don't need a high-end mainboard or CPUs on these projects. While it's a powerful tool for low-level debugging and understanding even part of it requires a fair amount of knowledge on x86 architecture, there are also challenges in the user interface development. The list below is a collection of improvement ideas and capabilities that would be nice to have. Some of these could be merged with [http://www.coreboot.org/GSoC coreboot GSoC] projects or support [http://www.flashrom.org/GSoC flashrom GSoC] projects. == SerialICE on target == * Build target ROM image with super-IO and PnP from coreboot tree. * Support EHCI debug port, extend the protocol for memory block moves. * Investigate possibilities to catch SMI and run System Management Mode. == SIMBA, the filtering subsystem == * Query PCI IDs to detect chipsets and load filters automatically. * Enable modifying SMBus traffic on-the-fly to forge SPD data for testing purposes. * Create log output conditionally of CS:EIP or accessed PCI device. * Decode PCI/PCI-e standard configuration registers. * Enable injection of IO and memory transactions. == User interface == * Well, provide one. Now it is just a logfile and a script. * Display SerialICE log in parallel with disassembly. Applications to consider are [http://rada.re/y/?p=features radare2] and [https://www.hex-rays.com/products/ida/index.shtml IDA] * Visualize PCI devicetree configuration sequence and allocations. * Integration with GDB and DDD. == Coreboot == * Collect IO and PCI transactions on boot and store them in cbmem. Replay them to see what devicetree really did during ramstage. * Complete and merge [http://www.coreboot.org/Project_Ideas#coreboot_panic_room coreboot panic room] results upstream. == QEMU == * Create hybrid platform, where some devices are emulated and some run on real hardware. * Update to a more current QEMU. * Support other architectures. 2a35b9ff76f544244506123368c7cd91e4cf63ad 30 28 2015-10-26T20:06:53Z Patrick Georgi 1 wikitext text/x-wiki The SerialICE project will hopefully participate in GSoC 2015 under the patronage of [http://coreboot.org/GSoC coreboot's GSoC administration]. Depending on the number and quality of applications, and available mentors, there might be room for a separate SerialICE project. If you're interested, please send your thoughts and ideas on the [http://www.serialice.com/mailman/listinfo/serialice mailing list] and come discuss them on IRC irc://irc.freenode.net/#coreboot. It is not likely that the project organisation would supply any hardware required to complete or even start a project on SerialICE. So if you want to apply, you should first try building and running SerialICE yourself to understand its current capabilities and weaknesses. You really don't need a high-end mainboard or CPUs on these projects. While it's a powerful tool for low-level debugging and understanding even part of it requires a fair amount of knowledge on x86 architecture, there are also challenges in the user interface development. The list below is a collection of improvement ideas and capabilities that would be nice to have. Some of these could be merged with [http://www.coreboot.org/GSoC coreboot GSoC] projects or support [http://www.flashrom.org/GSoC flashrom GSoC] projects. == SerialICE on target == * Build target ROM image with super-IO and PnP from coreboot tree. * Support EHCI debug port, extend the protocol for memory block moves. * Investigate possibilities to catch SMI and run System Management Mode. == SIMBA, the filtering subsystem == * Query PCI IDs to detect chipsets and load filters automatically. * Enable modifying SMBus traffic on-the-fly to forge SPD data for testing purposes. * Create log output conditionally of CS:EIP or accessed PCI device. * Decode PCI/PCI-e standard configuration registers. * Enable injection of IO and memory transactions. == User interface == * Well, provide one. Now it is just a logfile and a script. * Display SerialICE log in parallel with disassembly. Applications to consider are [http://rada.re/y/?p=features radare2] and [https://www.hex-rays.com/products/ida/index.shtml IDA] * Visualize PCI devicetree configuration sequence and allocations. * Integration with GDB and DDD. == Coreboot == * Collect IO and PCI transactions on boot and store them in cbmem. Replay them to see what devicetree really did during ramstage. * Complete and merge [http://www.coreboot.org/Project_Ideas#coreboot_panic_room coreboot panic room] results upstream. == QEMU == * Create hybrid platform, where some devices are emulated and some run on real hardware. * Update to a more current QEMU. * Support other architectures. == Port to Unicorn == [http://www.unicorn-engine.org/ Unicorn] may be a more suitable (and maybe even stable) base for our purposes than QEmu because it shares some of SerialICE's goals. Needs investigation if that's actually a good idea _before_ GSoC starts (although such an investigation is already a great way to show that you're capable of finishing this project) 7ec7156207d69d481cc8655ef24184e1d03e480e 31 30 2016-02-21T11:36:14Z Patrick Georgi 1 wikitext text/x-wiki The SerialICE project will hopefully participate in GSoC 2016 under the patronage of [http://coreboot.org/GSoC coreboot's GSoC administration]. Depending on the number and quality of applications, and available mentors, there might be room for a separate SerialICE project. If you're interested, please send your thoughts and ideas on the [http://www.serialice.com/mailman/listinfo/serialice mailing list] and come discuss them on IRC irc://irc.freenode.net/#coreboot. It is not likely that the project organisation would supply any hardware required to complete or even start a project on SerialICE. So if you want to apply, you should first try building and running SerialICE yourself to understand its current capabilities and weaknesses. You really don't need a high-end mainboard or CPUs on these projects. While it's a powerful tool for low-level debugging and understanding even part of it requires a fair amount of knowledge on x86 architecture, there are also challenges in the user interface development. The list below is a collection of improvement ideas and capabilities that would be nice to have. Some of these could be merged with [http://www.coreboot.org/GSoC coreboot GSoC] projects or support [http://www.flashrom.org/GSoC flashrom GSoC] projects. == SerialICE on target == * Build target ROM image with super-IO and PnP from coreboot tree. * Support EHCI debug port, extend the protocol for memory block moves. * Investigate possibilities to catch SMI and run System Management Mode. == SIMBA, the filtering subsystem == * Query PCI IDs to detect chipsets and load filters automatically. * Enable modifying SMBus traffic on-the-fly to forge SPD data for testing purposes. * Create log output conditionally of CS:EIP or accessed PCI device. * Decode PCI/PCI-e standard configuration registers. * Enable injection of IO and memory transactions. == User interface == * Well, provide one. Now it is just a logfile and a script. * Display SerialICE log in parallel with disassembly. Could be integrated with [http://rada.re/y/?p=features radare2] * Visualize PCI devicetree configuration sequence and allocations. * An editor that knows the log format and supports user-assisted folding of loops that wait for bit flips, naming of registers, ... * Integration with GDB and DDD. == coreboot == * Collect IO and PCI transactions on boot and store them in cbmem. Replay them to see what devicetree really did during ramstage. * Complete and merge [http://www.coreboot.org/Project_Ideas#coreboot_panic_room coreboot panic room] results upstream. == QEMU == * Update to a more current QEMU. * Support other architectures. * Create hybrid platform, where some devices are emulated and some run on real hardware. == Port to Unicorn == [http://www.unicorn-engine.org/ Unicorn] may be a more suitable (and maybe even stable) base for our purposes than QEmu because it shares some of SerialICE's goals. Needs investigation if that's actually a good idea _before_ GSoC starts (although such an investigation is already a great way to show that you're capable of finishing this project) 5c91b78b2ba1bbc0328173dd594855eabe93d981 0 11 25 2014-07-04T18:19:13Z Stefan Reinauer 2 Created page with " * Dynamic Analysis Kung-Fu with [http://amnesia.gtisc.gatech.edu/~moyix/PANDA_REcon.pdf PANDA] (Platform for Architecture Neutral Dynamic Analysis) * [http://goo.gl/rTZiJU Av..." wikitext text/x-wiki * Dynamic Analysis Kung-Fu with [http://amnesia.gtisc.gatech.edu/~moyix/PANDA_REcon.pdf PANDA] (Platform for Architecture Neutral Dynamic Analysis) * [http://goo.gl/rTZiJU Avatar] (Dynamic analysis/RE of your embedded devices in one picture) 91b46dc45931be4f6a5a7c280d58f21012b0e4b3 26 25 2014-07-04T18:19:41Z Stefan Reinauer 2 wikitext text/x-wiki * Dynamic Analysis Kung-Fu with [http://amnesia.gtisc.gatech.edu/~moyix/PANDA_REcon.pdf PANDA] (Platform for Architecture Neutral Dynamic Analysis) * [http://www.s3.eurecom.fr/tools/avatar/ Avatar] (Dynamic analysis/RE of your embedded devices in one picture) 51e1e8ed2abc0ffc4bec9ec0032d2cc514417be0 27 26 2014-07-04T18:20:20Z Stefan Reinauer 2 wikitext text/x-wiki * Dynamic Analysis Kung-Fu with [http://amnesia.gtisc.gatech.edu/~moyix/PANDA_REcon.pdf PANDA] - Platform for Architecture Neutral Dynamic Analysis * [http://www.s3.eurecom.fr/tools/avatar/ Avatar] - Avatar is an event-based arbitration framework that orchestrates the communication between an emulator and a target physical device 1585adf4c9c1abb5052d74b761affa8d7d7a51be